مدیریت ترافیک جنریک: تغییر پارادایم به سمت بهینه‌سازی جریان ایمن از نظر نوع

در دنیای سیستم‌های توزیع شده، مدیریت جریان ترافیک یک چالش اساسی است. برای دهه‌ها، ما سیستم‌های پیچیده‌تری را مهندسی کرده‌ایم تا بسته‌های شبکه را مسیریابی، متعادل و ایمن کنیم. از متعادل‌کننده‌های بار سخت‌افزاری ساده گرفته تا مش‌های سرویس مدرن و غنی از ویژگی‌ها، هدف ثابت باقی مانده است: اطمینان از اینکه درخواست A به سرویس B به طور قابل اعتماد و کارآمد می‌رسد. با این حال، یک محدودیت ظریف اما عمیق در بیشتر این سیستم‌ها وجود داشته است: آنها تا حد زیادی ناآگاه از نوع هستند. آنها داده‌های برنامه را به عنوان یک محموله غیرشفاف در نظر می‌گیرند و بر اساس فراداده L3/L4 مانند آدرس‌های IP و پورت‌ها، یا در بهترین حالت، داده‌های L7 کم‌عمق مانند هدرهای HTTP، تصمیم‌گیری می‌کنند. این در حال تغییر است.

ما در آستانه یک تغییر پارادایم در مدیریت ترافیک هستیم - حرکتی از دنیای ناآگاه از نوع به یک دنیای آگاه از نوع. این تکامل، که ما آن را بهینه‌سازی جریان ایمن از نظر نوع می‌نامیم، در مورد جاسازی مفهوم قراردادهای داده و طرحواره‌ها به طور مستقیم در خود زیرساخت شبکه است. این در مورد توانمندسازی گیت‌وی‌های API، مش‌های سرویس و پراکسی‌های لبه ما برای درک ساختار و معنای واقعی داده‌هایی است که مسیریابی می‌کنند. این فقط یک تمرین آکادمیک نیست؛ بلکه یک ضرورت عملی برای ساخت نسل بعدی برنامه‌های انعطاف‌پذیر، امن و مقیاس‌پذیر جهانی است. این پست بررسی می‌کند که چرا ایمنی نوع در لایه ترافیک، مرز جدیدی است، چگونه چنین سیستم‌هایی را معماری کنیم و چه مزایای تحول‌آفرینی به همراه دارد.

سفر از انتقال بسته به آگاهی L7

برای قدردانی از اهمیت ایمنی نوع، نگاهی به تکامل مدیریت ترافیک مفید است. این سفر، سفری از بازرسی و هوش عمیق‌تر به طور فزاینده بوده است.

فاز 1: عصر متعادل‌سازی بار L3/L4

در روزهای اولیه وب، مدیریت ترافیک ساده بود. یک متعادل‌کننده بار سخت‌افزاری در مقابل مجموعه‌ای از سرورهای وب یکپارچه قرار داشت. وظیفه آن توزیع اتصالات TCP ورودی بر اساس الگوریتم‌های ساده مانند round-robin یا کمترین اتصال بود. این عمدتاً در لایه‌های 3 (IP) و 4 (TCP/UDP) مدل OSI عمل می‌کرد. متعادل‌کننده بار هیچ مفهومی از HTTP، JSON یا gRPC نداشت؛ فقط اتصالات و بسته‌ها را می‌دید. این برای زمان خود موثر بود، اما با پیچیده‌تر شدن برنامه‌ها، محدودیت‌های آن آشکار شد.

فاز 2: ظهور هوش L7

با ظهور میکروسرویس‌ها و APIهای پیچیده، متعادل‌سازی ساده در سطح اتصال دیگر کافی نبود. ما باید بر اساس داده‌های سطح برنامه تصمیمات مسیریابی می‌گرفتیم. این امر منجر به ظهور پراکسی‌های L7 و کنترل‌کننده‌های تحویل برنامه (ADC) شد. این سیستم‌ها می‌توانستند هدرهای HTTP، URLها و کوکی‌ها را بررسی کنند.

این امکان قابلیت‌های جدید قدرتمندی را فراهم کرد:

• مسیریابی مبتنی بر مسیر: مسیریابی /api/users به سرویس کاربر و /api/orders به سرویس سفارش.
• مسیریابی مبتنی بر میزبان: هدایت ترافیک برای emea.mycompany.com و apac.mycompany.com به مجموعه‌های سرور مختلف.
• جلسات چسبنده: استفاده از کوکی‌ها برای اطمینان از اینکه یک کاربر همیشه به همان سرور پشتیبان ارسال می‌شود.

ابزارهایی مانند NGINX، HAProxy و بعداً، پراکسی‌های بومی ابری مانند Envoy، به سنگ بنای معماری‌های مدرن تبدیل شدند. مش سرویس، که توسط این پراکسی‌های L7 تغذیه می‌شد، با استقرار آنها به عنوان sidecar در هر سرویس، یک قدم فراتر رفت و یک پارچه شبکه فراگیر و آگاه از برنامه ایجاد کرد.

نقطه کور باقی‌مانده: محموله غیرشفاف

علیرغم این پیشرفت، یک نقطه کور حیاتی باقی مانده است. در حالی که زیرساخت ما روش‌ها و هدرهای HTTP را درک می‌کند، به طور کلی با بدنه درخواست—محموله داده واقعی—به عنوان یک حباب غیرشفاف از بایت‌ها برخورد می‌کند. پراکسی ممکن است بداند که در حال مسیریابی یک درخواست POST به /api/v1/users با هدر Content-Type: application/json است، اما هیچ ایده‌ای ندارد که ساختار آن JSON چگونه باید باشد. آیا فیلد الزامی `email` از دست رفته است؟ آیا `user_id` یک عدد صحیح است در حالی که باید یک رشته باشد؟ آیا مشتری یک محموله v1 را به یک نقطه پایانی v2 ارسال می‌کند که ساختار متفاوتی را انتظار دارد؟

امروزه، این بار اعتبارسنجی تقریباً به طور کامل بر عهده کد برنامه است. هر میکروسرویس باید درخواست‌های بدشکل را اعتبارسنجی، سریال‌زدایی و مدیریت کند. این منجر به مجموعه‌ای از مشکلات می‌شود:

• کد اضافی: هر سرویس منطق اعتبارسنجی boilerplate یکسانی را می‌نویسد.
• اجرای ناسازگار: سرویس‌های مختلف، که احتمالاً توسط تیم‌های مختلف در زبان‌های مختلف نوشته شده‌اند، ممکن است قوانین اعتبارسنجی را به طور ناسازگار اجرا کنند.
• خطاهای زمان اجرا: درخواست‌های بدشکل به عمق شبکه نفوذ می‌کنند و باعث می‌شوند سرویس‌ها خراب شوند یا خطاهای 500 مبهم را برگردانند و اشکال‌زدایی را دشوار کنند.
• آسیب‌پذیری‌های امنیتی: عدم اعتبارسنجی دقیق ورودی در لبه، بردار اصلی برای حملاتی مانند تزریق NoSQL، آسیب‌پذیری‌های تخصیص انبوه و سایر سوء استفاده‌های مبتنی بر محموله است.
• منابع هدر رفته: یک سرویس backend چرخه‌های CPU را صرف پردازش یک درخواست می‌کند فقط برای اینکه متوجه شود نامعتبر است و باید رد شود.

تعریف ایمنی نوع در جریان‌های شبکه

وقتی توسعه‌دهندگان عبارت "ایمنی نوع" را می‌شنوند، اغلب به زبان‌های برنامه‌نویسی مانند TypeScript، Rust یا Java فکر می‌کنند که خطاهای مربوط به نوع را در زمان کامپایل تشخیص می‌دهند. این قیاس به طرز باورنکردنی برای مدیریت ترافیک مناسب است. بهینه‌سازی جریان ایمن از نظر نوع، هدفش شناسایی تخلفات قرارداد داده در لبه زیرساخت است - نوعی "زمان کامپایل" شبکه - قبل از اینکه باعث خطاهای زمان اجرا در سرویس‌های شما شوند.

ایمنی نوع در این زمینه بر روی چند ستون اصلی بنا شده است:

1. قراردادهای داده مبتنی بر طرحواره

اساس ایمنی نوع، تعریف رسمی ساختارهای داده است. تیم‌ها به جای تکیه بر توافقات موقت یا مستندات، از یک زبان تعریف طرحواره قابل خواندن توسط ماشین (SDL) برای ایجاد یک قرارداد بی‌ابهام برای یک API استفاده می‌کنند.

انتخاب‌های محبوب عبارتند از:

• OpenAPI (قبلاً Swagger): استانداردی برای توصیف APIهای RESTful، تعریف نقاط پایانی، متدها، پارامترها و طرحواره‌های JSON/YAML برای بدنه‌های درخواست و پاسخ.
• پروتکل بافرها (Protobuf): یک فرمت سریال‌سازی باینری که توسط گوگل توسعه یافته است، اغلب با gRPC استفاده می‌شود. این مستقل از زبان و بسیار کارآمد است.
• JSON Schema: واژگانی که به شما امکان می‌دهد اسناد JSON را حاشیه‌نویسی و اعتبارسنجی کنید.
• Apache Avro: یک سیستم سریال‌سازی داده که در برنامه‌های کاربردی با داده‌های فشرده، به ویژه در اکوسیستم Apache Kafka، محبوب است.

این طرحواره به منبع واحد حقیقت برای مدل داده یک سرویس تبدیل می‌شود.

2. اعتبارسنجی در سطح زیرساخت

تغییر کلیدی، انتقال اعتبارسنجی از برنامه به زیرساخت است. صفحه داده—گیت‌وی API یا پراکسی‌های مش سرویس شما—با طرحواره‌های سرویس‌هایی که از آنها محافظت می‌کند، پیکربندی شده است. وقتی یک درخواست می‌رسد، پراکسی قبل از ارسال آن، یک فرآیند دو مرحله‌ای را انجام می‌دهد:

1. سریال‌زدایی: بدنه درخواست خام (به عنوان مثال، یک رشته JSON یا داده‌های باینری Protobuf) را به یک نمایش ساختاریافته تجزیه می‌کند.
2. اعتبارسنجی: این داده‌های ساختاریافته را در برابر طرحواره ثبت‌شده بررسی می‌کند. آیا همه فیلدهای مورد نیاز را دارد؟ آیا انواع داده صحیح هستند (به عنوان مثال، آیا `age` یک عدد است)؟ آیا با هیچ محدودیتی مطابقت دارد (به عنوان مثال، آیا `country_code` یک رشته دو حرفی است که با یک لیست از پیش تعریف‌شده مطابقت دارد)؟

اگر اعتبارسنجی ناموفق باشد، پراکسی بلافاصله درخواست را با یک خطای توصیفی 4xx (به عنوان مثال، `400 Bad Request`) رد می‌کند، از جمله جزئیات مربوط به خرابی اعتبارسنجی. درخواست نامعتبر حتی به سرویس برنامه نمی‌رسد. این به عنوان اصل Fail Fast شناخته می‌شود.

3. مسیریابی آگاه از نوع و اجرای سیاست

هنگامی که زیرساخت ساختار داده را درک کرد، می‌تواند تصمیمات بسیار هوشمندانه‌تری بگیرد. این بسیار فراتر از تطبیق ساده URL است.

• مسیریابی مبتنی بر محتوا: می‌توانید قوانین مسیریابی را بر اساس مقادیر فیلدهای خاص در محموله ایجاد کنید. به عنوان مثال: "اگر `request.body.user.tier == 'premium'`، به `premium-cluster` با عملکرد بالا مسیریابی کنید. در غیر این صورت، به `standard-cluster` مسیریابی کنید." این بسیار قوی‌تر از تکیه بر یک هدر است که به راحتی می‌تواند حذف یا جعل شود.
• اجرای دقیق سیاست: سیاست‌های امنیتی و تجاری را می‌توان با دقت جراحی اعمال کرد. به عنوان مثال، یک قانون فایروال برنامه وب (WAF) می‌تواند به گونه‌ای پیکربندی شود که "هر درخواست `update_user_profile` را که در آن فیلد `role` در حال تغییر به `admin` است، مسدود کند، مگر اینکه درخواست از یک محدوده IP داخلی منشأ گرفته باشد."
• نسخه‌بندی طرحواره برای تغییر ترافیک: در طول یک مهاجرت، می‌توانید ترافیک را بر اساس نسخه طرحواره مسیریابی کنید. "درخواست‌هایی که با `OrderSchema v1` مطابقت دارند به مونولیت قدیمی می‌روند، در حالی که درخواست‌هایی که با `OrderSchema v2` مطابقت دارند به میکروسرویس جدید ارسال می‌شوند." این امکان استقرارهای ایمن‌تر و کنترل‌شده‌تری را فراهم می‌کند.

معماری یک سیستم مدیریت ترافیک ایمن از نظر نوع

پیاده‌سازی چنین سیستمی نیازمند یک معماری منسجم با سه جزء اصلی است: یک رجیستری طرحواره، یک صفحه کنترل پیچیده و یک صفحه داده هوشمند.

1. رجیستری طرحواره: منبع حقیقت

رجیستری طرحواره یک مخزن متمرکز است که همه قراردادهای داده (طرحواره‌ها) را برای سرویس‌های سازمان شما ذخیره و نسخه‌بندی می‌کند. این به عنوان منبع بدون اختلاف حقیقت برای نحوه ارتباط سرویس‌ها عمل می‌کند.

• تمرکز: یک مکان واحد را برای همه تیم‌ها فراهم می‌کند تا طرحواره‌ها را کشف و بازیابی کنند و از تکه‌تکه شدن طرحواره جلوگیری می‌کند.
• نسخه‌بندی: تکامل طرحواره‌ها را در طول زمان مدیریت می‌کند (به عنوان مثال، v1، v2، v2.1). این برای رسیدگی به سازگاری رو به عقب و رو به جلو بسیار مهم است.
• بررسی‌های سازگاری: یک رجیستری طرحواره خوب می‌تواند قوانین سازگاری را اعمال کند. به عنوان مثال، می‌تواند از فشار دادن یک نسخه طرحواره جدید توسط یک توسعه‌دهنده که مشتریان موجود را خراب می‌کند (به عنوان مثال، با حذف یک فیلد مورد نیاز) جلوگیری کند. رجیستری طرحواره Confluent برای Avro یک نمونه شناخته شده در دنیای جریان داده است که این قابلیت‌ها را ارائه می‌دهد.

2. صفحه کنترل: مغز عملیات

صفحه کنترل، هاب پیکربندی و مدیریت است. این جایی است که اپراتورها و توسعه‌دهندگان سیاست‌ها و قوانین مسیریابی را تعریف می‌کنند. در یک سیستم ایمن از نظر نوع، نقش صفحه کنترل ارتقا می‌یابد.

• تعریف سیاست: یک API یا UI برای تعریف قصد سطح بالا، مانند "اعتبارسنجی تمام ترافیک به `payment-service` در برابر `PaymentRequestSchema v3`." فراهم می‌کند.
• ادغام طرحواره: با رجیستری طرحواره ادغام می‌شود تا طرحواره‌های لازم را بکشد.
• گردآوری پیکربندی: قصد سطح بالا و طرحواره‌های مربوطه را می‌گیرد و آنها را به پیکربندی‌های سطح پایین و ملموس تبدیل می‌کند که پراکسی‌های صفحه داده می‌توانند درک کنند. این مرحله "زمان کامپایل شبکه" است. اگر یک اپراتور سعی کند قانونی ایجاد کند که به یک فیلد غیر موجود اشاره کند (به عنوان مثال، `request.body.user.t_ier` با یک غلط املایی)، صفحه کنترل می‌تواند آن را در زمان پیکربندی رد کند.
• توزیع پیکربندی: پیکربندی گردآوری‌شده را به طور ایمن به تمام پراکسی‌های مربوطه در صفحه داده هل می‌دهد. Istio و Open Policy Agent (OPA) نمونه‌هایی از فناوری‌های قدرتمند صفحه کنترل هستند.

3. صفحه داده: مجریان

صفحه داده از پراکسی‌های شبکه (به عنوان مثال، Envoy، NGINX) تشکیل شده است که در مسیر هر درخواست قرار دارند. آنها پیکربندی خود را از صفحه کنترل دریافت می‌کنند و قوانین را بر روی ترافیک زنده اجرا می‌کنند.

• پیکربندی پویا: پراکسی‌ها باید بتوانند پیکربندی خود را به صورت پویا بدون قطع اتصالات به‌روزرسانی کنند. API xDS Envoy استاندارد طلایی برای این موضوع است.
• اعتبارسنجی با کارایی بالا: اعتبارسنجی سربار اضافه می‌کند. پراکسی‌ها باید در سریال‌زدایی و اعتبارسنجی محموله‌ها بسیار کارآمد باشند تا تأخیر را به حداقل برسانند. این اغلب با استفاده از کتابخانه‌های با عملکرد بالا که در زبان‌هایی مانند C++ یا Rust نوشته شده‌اند، به دست می‌آید، که گاهی اوقات از طریق WebAssembly (Wasm) یکپارچه می‌شوند.
• تله‌متری غنی: هنگامی که یک درخواست به دلیل خرابی اعتبارسنجی رد می‌شود، پراکسی باید گزارش‌ها و معیارهای دقیق را منتشر کند. این تله‌متری برای اشکال‌زدایی و نظارت بسیار ارزشمند است و به تیم‌ها امکان می‌دهد تا به سرعت مشتریان بدرفتار یا مشکلات یکپارچه‌سازی را شناسایی کنند.

مزایای تحول‌آفرین بهینه‌سازی جریان ایمن از نظر نوع

اتخاذ یک رویکرد ایمن از نظر نوع برای مدیریت ترافیک فقط در مورد افزودن یک لایه اعتبارسنجی دیگر نیست. بلکه در مورد بهبود اساسی نحوه ساخت و بهره‌برداری از سیستم‌های توزیع شده است.

قابلیت اطمینان و انعطاف‌پذیری بیشتر

با انتقال اجرای قرارداد به لبه شبکه، یک حریم دفاعی قدرتمند ایجاد می‌کنید. داده‌های نامعتبر قبل از اینکه باعث خرابی‌های آبشاری شوند، متوقف می‌شوند. این رویکرد "تغییر به چپ" به اعتبارسنجی داده‌ها به این معنی است که خطاها زودتر شناسایی می‌شوند، تشخیص آنها آسان‌تر است و تأثیر کمتری دارند. سرویس‌ها انعطاف‌پذیرتر می‌شوند زیرا می‌توانند به این اعتماد کنند که هر درخواستی که دریافت می‌کنند به خوبی شکل گرفته است و به آنها اجازه می‌دهد تا فقط بر منطق تجاری تمرکز کنند.

وضعیت امنیتی به شدت بهبود یافته

بخش قابل توجهی از آسیب‌پذیری‌های وب ناشی از اعتبارسنجی نادرست ورودی است. با اجرای یک طرحواره دقیق در لبه، شما کل کلاس‌های حملات را به طور پیش فرض خنثی می‌کنید.

• حملات تزریقی: اگر یک فیلد در طرحواره به عنوان یک بولی تعریف شده باشد، تزریق یک رشته حاوی کد مخرب غیرممکن است.
• انکار سرویس (DoS): طرحواره‌ها می‌توانند محدودیت‌هایی را بر روی طول آرایه یا اندازه‌های رشته اعمال کنند و از حملاتی که از محموله‌های بزرگ برای تخلیه حافظه استفاده می‌کنند، جلوگیری کنند.
• قرار گرفتن در معرض داده‌ها: می‌توانید طرحواره‌های پاسخ را نیز تعریف کنید و اطمینان حاصل کنید که سرویس‌ها به طور تصادفی فیلدهای حساس را نشت نمی‌دهند. پراکسی می‌تواند هر فیلد غیر منطبق را قبل از ارسال پاسخ به مشتری فیلتر کند.

توسعه و انطباق سریع‌تر

هنگامی که قراردادهای داده صریح هستند و توسط زیرساخت اجرا می‌شوند، بهره‌وری توسعه‌دهنده به شدت افزایش می‌یابد.

• قراردادهای روشن: تیم‌های frontend و backend، یا تیم‌های سرویس به سرویس، یک قرارداد بی‌ابهام برای کار دارند. این اصطکاک و سوء تفاهم‌های یکپارچه‌سازی را کاهش می‌دهد.
• کد تولید شده خودکار: از طرحواره‌ها می‌توان برای تولید خودکار کتابخانه‌های مشتری، stubهای سرور و مستندات به چندین زبان استفاده کرد و در زمان توسعه قابل توجهی صرفه‌جویی کرد.
• اشکال‌زدایی سریع‌تر: وقتی یک یکپارچه‌سازی ناموفق می‌شود، توسعه‌دهندگان بازخورد فوری و دقیق از لایه شبکه دریافت می‌کنند ("فیلد 'productId' از دست رفته است") به جای یک خطای عمومی 500 از سرویس.

سیستم‌های کارآمد و بهینه‌سازی شده

خارج کردن اعتبارسنجی به یک لایه زیرساخت مشترک، که اغلب یک sidecar بسیار بهینه‌سازی شده است که در C++ نوشته شده است، بسیار کارآمدتر از این است که هر سرویس، که احتمالاً در یک زبان کندتر و تفسیر شده مانند Python یا Ruby نوشته شده است، همان کار را انجام دهد. این چرخه‌های CPU برنامه را برای آنچه مهم است آزاد می‌کند: منطق تجاری. علاوه بر این، استفاده از فرمت‌های باینری کارآمد مانند Protobuf، که توسط مش اعمال می‌شود، می‌تواند به طور قابل توجهی پهنای باند شبکه و تأخیر را در مقایسه با JSON پرمخاطب کاهش دهد.

چالش‌ها و ملاحظات دنیای واقعی

در حالی که این دیدگاه قانع‌کننده است، مسیر پیاده‌سازی چالش‌هایی دارد. سازمان‌هایی که این معماری را در نظر می‌گیرند باید برای آنها برنامه‌ریزی کنند.

1. سربار عملکرد

سریال‌زدایی و اعتبارسنجی محموله رایگان نیست. آنها تأخیر را به هر درخواست اضافه می‌کنند. تأثیر بستگی به اندازه محموله، پیچیدگی طرحواره و کارایی موتور اعتبارسنجی پراکسی دارد. برای برنامه‌های کاربردی با تأخیر بسیار کم، این سربار ممکن است نگران‌کننده باشد. استراتژی‌های کاهش عبارتند از:

• استفاده از فرمت‌های باینری کارآمد (Protobuf).
• پیاده‌سازی منطق اعتبارسنجی در ماژول‌های Wasm با عملکرد بالا.
• اعمال انتخابی اعتبارسنجی فقط برای نقاط پایانی حیاتی یا بر اساس نمونه‌گیری.

2. پیچیدگی عملیاتی

معرفی یک رجیستری طرحواره و یک صفحه کنترل پیچیده‌تر، اجزای جدیدی را برای مدیریت، نظارت و نگهداری اضافه می‌کند. این نیازمند سرمایه‌گذاری در اتوماسیون زیرساخت و تخصص تیمی است. منحنی یادگیری اولیه برای اپراتورها می‌تواند تند باشد.

3. تکامل و حکمرانی طرحواره

این احتمالاً بزرگترین چالش اجتماعی-فنی است. چه کسی مالک طرحواره‌ها است؟ چگونه تغییرات پیشنهاد، بررسی و استقرار می‌یابند؟ چگونه نسخه‌بندی طرحواره را بدون شکستن مشتریان مدیریت می‌کنید؟ یک مدل حکمرانی قوی ضروری است. تیم‌ها باید در مورد بهترین شیوه‌ها برای تغییرات طرحواره سازگار رو به عقب و رو به جلو آموزش ببینند. رجیستری طرحواره باید ابزارهایی را برای اجرای این قوانین حکمرانی ارائه دهد.

4. اکوسیستم ابزار

در حالی که همه اجزای منفرد وجود دارند (Envoy برای صفحه داده، OpenAPI/Protobuf برای طرحواره‌ها، OPA برای سیاست)، راه‌حل‌های کاملاً یکپارچه و کلید در دست برای مدیریت ترافیک ایمن از نظر نوع هنوز در حال ظهور هستند. بسیاری از سازمان‌ها، مانند شرکت‌های بزرگ فناوری جهانی، مجبور شده‌اند بخش‌های قابل توجهی از این ابزار را در داخل شرکت بسازند. با این حال، جامعه منبع باز به سرعت در این مسیر حرکت می‌کند و پروژه‌های مش سرویس به طور فزاینده‌ای قابلیت‌های اعتبارسنجی پیچیده‌تری را اضافه می‌کنند.

آینده آگاه از نوع است

حرکت از مدیریت ترافیک ناآگاه از نوع به ایمن از نظر نوع، مسئله "اگر" نیست، بلکه "چه زمانی" است. این نشان دهنده بلوغ منطقی زیرساخت شبکه ما است و آن را از یک فشار دهنده ساده بسته به یک نگهبان هوشمند و آگاه از زمینه سیستم‌های توزیع شده ما تبدیل می‌کند. با جاسازی قراردادهای داده به طور مستقیم در پارچه شبکه، سیستم‌هایی می‌سازیم که از نظر طراحی قابل اطمینان‌تر، از نظر پیش‌فرض امن‌تر و در عملکرد خود کارآمدتر هستند.

این سفر نیازمند سرمایه‌گذاری استراتژیک در ابزارها، معماری و فرهنگ است. این مستلزم آن است که ما با طرحواره‌های داده خود نه به عنوان مستندات صرف، بلکه به عنوان شهروندان درجه یک و قابل اجرا در زیرساخت خود رفتار کنیم. برای هر سازمان جهانی که در مورد مقیاس‌بندی معماری میکروسرویس خود، بهینه‌سازی سرعت توسعه‌دهنده و ساخت سیستم‌های واقعاً انعطاف‌پذیر جدی است، اکنون زمان شروع بررسی بهینه‌سازی جریان ایمن از نظر نوع است. آینده مدیریت ترافیک فقط داده‌های شما را مسیریابی نمی‌کند. بلکه آن را درک می‌کند.